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Abstract — Next Generation Air Transportation System (NextGen) 
applications reliant upon aircraft data links such as Automatic 
Dependent Surveillance-Broadcast (ADS-B) offer a sweeping 
modernization of the National Airspace System (NAS), but the 
aviation stakeholder community has not yet established a positive 
business case for equipage and message content standards remain 
in flux. It is necessary to transition promising Air Traffic 
Management (ATM) Concepts of Operations (ConOps) from 
simulation environments to full-scale flight tests in order to 
validate user benefits and solidify message standards. However, 
flight tests are prohibitively expensive and message standards for 
Commercial-off-the-Shelf (COTS) systems cannot support many 
advanced ConOps. It is therefore proposed to simulate future 
aircraft surveillance and communications equipage and employ 
an existing commercial data link to exchange data during 
dedicated flight tests. This capability, referred to as the 
Networked Air Traffic Infrastructure Validation Environment 
(NATIVE), would emulate aircraft data links such as ADS-B 
using in-flight Internet and easily-installed test equipment. By 
utilizing low-cost equipment that is easy to install and certify for 
testing, advanced ATM ConOps can be validated, message 
content standards can be solidified, and new standards can be 
established through full-scale flight trials without necessary or 
expensive equipage or extensive flight test preparation. This 
paper presents results of a feasibility study of the NATIVE 
concept. To determine requirements, six NATIVE design 
configurations were developed for two NASA ConOps that rely 
on ADS-B. The performance characteristics of three existing in- 
flight Internet services were investigated to determine whether 
performance is adequate to support the concept. Next, a study of 
requisite hardware and software was conducted to examine 
whether and how the NATIVE concept might be realized. 
Finally, to determine a business case, economic factors were 
evaluated and a preliminary cost-benefit analysis was performed. 
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I. Introduction 

Air Traffic Management (ATM) Concepts of Operation 
(ConOps) that rely on advanced technologies such Automatic 
Dependent Surveillance-Broadcast (ADS-B), Controller/Pilot 
Data Link Communications (CPDLC), airborne and ground- 
based automation, and advanced controller and pilot interfaces 
have been developed and investigated by NASA, the Federal 
Aviation Administration (FAA), and others over recent 
decades. Research and development to date for concepts that 
rely on the exchange of data between aircraft or between 
ground systems and aircraft have almost exclusively been 
conducted using modeling, analysis, and Human-in-the-Loop 
(HITL) simulation. To continue progress toward 
implementation of these advanced ConOps as future elements 
of the National Airspace System (NAS), extensive validation 
and refinement must occur in the environments of their 
ultimate use. 

Due to their high cost, flight activities associated with ATM 
concepts have often been limited to isolated demonstrations of 
capability. For many advanced concepts, extensive validation 
involving multiple field tests is required. The enabling 
technologies, their performance and interoperability standards, 
and their design requirements will require updates based on 
results of the in-flight concept validation and refinement. 
However, equipping many aircraft with the new systems and 
supporting avionics often requires a resource-intensive multi- 
year commitment to in-flight validation for a single flight test. 
Reducing these cost and time factors may be critical in meeting 
modernization expectations for the ConOps and their enabling 
technologies. 
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In addition, commercially available systems comply with 
existing standards, such as the Minimum Operational 
Performance Standards for ADS-B (currently RTCA DO-260B 
for the 1090 MHz ES standard). These standards do not include 
some of the message content proposed to support many 
advanced ConOps that may be necessary to provide acceptable 
returns-on-investment (ROI) demanded by airspace users to 
justify the expense of equipping their fleets. In addition, some 
ConOps may rely on the surveillance of very large numbers of 
targets. ADS-B In is currently limited to surveillance of 127 
aircraft. [1] Because these advanced concepts cannot be 
validated using currently-available ADS-B systems, there may 
be no way to validate these concepts in flight, and therefore, no 
way to justify the expense of extending the standards. 
Currently-available production systems may have limited value 
to owners of aircraft, so they have little incentive to equip and 
participate as partners in flight tests. Another approach is 
needed for in-flight evaluation of concepts that rely on ADS-B, 
CPDLC, and other advanced communications and surveillance 
concepts or technologies. 

It is proposed to conduct in-flight validation using a two- 
way data link that connects simulations of future airborne 
surveillance and communications equipage on each 
participating aircraft in lieu of actual equipment. A new 
capability, referred to as the Networked Air Traffic 
Infrastructure Validation Environment (NATIVE), emulates 
aircraft data links such as ADS-B using easily-installed test 
equipment and a small ground-based system of computers. 
NATIVE would be used in dedicated flight tests using either 
test aircraft or aircraft that are removed from revenue service 
for the test. A deployed NATIVE system would provide 
equipage and software that emulates an end-state system that 
relies on current and potential future ADS-B functions, CPDLC 
functions, and other functions for air-to-air and air/ground data 
exchange. The airborne NATIVE equipment would be installed 
and flown in an experimental certification. NATIVE may be 
able to utilize existing in-flight Internet systems and existing 
real-time simulations of the advanced data links, thereby 
keeping its development and implementation costs low. 

If NATIVE is adopted as a flight test method, airlines and 
other aircraft providers would be able to participate in 
NASA/FAA in situ validation trials and experiments by 
allowing NATIVE equipage to be installed on their aircraft on 
a temporary basis. In one potential use strategy, NASA would 
provide computing platforms to be installed in each 
participating aircraft as well as the ground-based component. In 
addition to the data link simulations, the airborne equipage 
would contain pre-installed and pre-tested NASA automation 
and display technologies. The ground-based component would 
be connected to existing FAA automation systems such as En 
Route Automation Modernization (ERAM), to other 
information services, and to platforms containing advanced 
ground-based technologies that support the ConOps under 
evaluation. 

This paper presents results of a feasibility study of the 
NATIVE concept. To determine requirements, six NATIVE 
design configurations were evaluated for two NASA ConOps 
that rely on ADS-B and other data links. The performance 
characteristics of three existing in-flight Internet Service 


Providers (ISP) were investigated to determine whether 
existing performance is sufficient to support the concept. Next, 
a study of requisite hardware and software was conducted to 
examine whether and how the NATIVE concept may be 
realized. Finally, to determine a business case, economic 
factors were evaluated and a preliminary cost-benefit analysis 
was performed. 

II. Anticipated Benefits 

NATIVE may prove to bridge the gap between research 
and development and implementation of advanced ATM 
ConOps and their enabling communication and surveillance 
technologies. Anticipated benefits of NATIVE are: 

• Costs of flight trials are mitigated for specific airborne 
functions that rely on advanced technologies or new 
standards for communication and surveillance. Cost 
reduction is achieved by reducing or eliminating the 
requirements to procure and permanently install 
certified equipment on aircraft to enable participation 
in the test. 

• Flight trial preparation time is substantially reduced 
since aircraft are equipped with existing test hardware 
on a temporary basis, new functional capabilities are 
provided from outside the aircraft, and the new 
capabilities already exist in simulation laboratories in 
some instances. Test hardware would be designed for 
minimal aircraft recertification to participate in 
multiple flight trials. 

• Because of the substantially-reduced costs, more 
aircraft are available to use a function during the flight 
trial, thereby allowing measurement of system benefits 
for concepts that rely on a large percentage of the 
aircraft being equipped and participating. 

• Costs incurred by airline partners in NASA/FAA flight 
trials are reduced. This may increase the pool of 
airlines and other airspace users available to participate 
as partners in government flight validation activities. 

• A virtual representation of communication and 
surveillance technology rather than reliance on actual 
hardware enables the exploration and validation of 
communication, navigation, and surveillance (CNS) 
requirements in situ. Simulations of future hardware 
are easily modifiable to explore and test potential new 
standards for message content and transfer rate. Test 
hardware will not become obsolete as a result of CNS 
standards changes, and the virtual environment will 
enable rapid update of the test system as standards 
evolve. 

• Simulated aircraft may augment the actual aircraft in 
the test, thereby increasing complexity of test scenarios 
with a minimal increase in costs. 

• Research algorithms and crew interface software stay 
on the research platforms on which they were 
developed and tested, thereby reducing costs, 
preparation time, and flight trial execution risk. 
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• If a research organization provides portable and easily 
site-adaptable system components, the components can 
be reused many times at many sites. Test planning, 
coordination, and set-up times could be reduced to the 
level where the rate of testing is several times greater 
than the rate achievable if certified flight hardware is 
employed. 

III. NATIVE Arcitechture 

As envisioned, NATIVE would utilize Commercial-off-the- 
Shelf (COTS) hardware as well as specifically-developed 
software components to emulate future surveillance and 
communication equipage for experimental flight tests. 

A. Hardware 

NATIVE hardware includes laptop or tablet computers 
installed on participating aircraft, ground-based computers with 
Internet access, and an in-flight Internet system. The airborne 
hardware would host displays and user input capabilities that 
support the ConOps under evaluation, and would be operated 
by the pilot or the flight test engineer. This equipment provides 
connectivity to the airborne Internet data link and hosts 
advanced ConOps algorithms, the associated aircraft data 
interfaces, and special processing functions as needed. An 
Electronic Flight Bag (EFB) may be used as the host platform. 
Modern aircraft that are compliant with ARINC Characteristic 
702A Revision 1, such as the Boeing 737NG, make Flight 
Management System (FMS) information available to the 
ARINC 429 data bus. This information is sufficient to 
investigate many proposed ConOps, and is accessed through 
the use of an EFB data concentrator or data concentrator 


emulation software. The information will only be received 
from aircraft systems; providing data from the advanced 
technology back to the aircraft systems is not a part of the 
envisioned NATIVE use. Flight crews will fly manually based 
on the NATIVE display guidance or will enter the displayed 
information into aircraft systems manually. 

In-flight Internet transmits and receives emulated aircraft 
surveillance and communication data between all participating 
aircraft and the NATIVE ground system. The ground system 
aggregates and processes traffic and weather information and, 
in some cases, hosts the advanced ATM technologies. 

Figure 1 illustrates a NATIVE test configuration for a 
future concept that makes use of ADS-B for airborne 
surveillance. Airborne and ground-based technologies are 
hosted by NATIVE to enable in situ evaluation of an integrated 
air/ground traffic management concept. ADS-B surveillance is 
simulated. The airborne NATIVE component of each 
participating aircraft constructs the simulated ADS-B Out 
message and sends it over the Internet downlink to the 
NATIVE ground component. The ground component receives 
simulated ADS-B broadcast messages from all participating 
aircraft and assembles a continuously-updated traffic 
surveillance data base. It can also accept traffic information 
from existing FAA traffic automation systems such as ERAM 
and from traffic simulators that generate virtual traffic. The 
ground-based component then provides traffic information to 
both the ground-based NASA automation technology and the 
airborne technologies. 
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Figure 1: A potential NATIVE test configuration for a concept that uses ADS-B for airborne surveillance. 
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B. Software 

NATIVE software components include data link reception 
and broadcast simulations, and software that amalgamates 
traffic and weather data from the participating aircraft and any 
other sources required for a given test. The NATIVE hardware 
may also host the advanced ConOps algorithms and any 
associated operator interfaces for both flight deck and ground- 
based applications. If needed for the test scenario, virtual traffic 
generators, traffic filtering, and data fusion algorithms can also 
be hosted by the NATIVE system. 

ADS-B reception and broadcast models developed by 
NASA for use in real-time simulation may be used to package, 
transfer, and receive information over the Internet. Similar 
models also exist for data links such as CPDLC. The ADS-B 
Out model uses data from the hosting aircraft’s systems, 
constructs an ADS-B broadcast message, and transfers it over 
the Internet. The ADS-B In model receives emulated ADS-B 
Out data over the Internet for all aircraft. It then determines 
whether each actual ADS-B message would have been received 
based on the originating aircraft’s range and transmit power, 
and whether interference would have prevented reception [2], 
ADS-B message standards are still in flux, so content and 
format remain subject to change. The NASA real-time ADS-B 
simulation can support additional messages as well as the 
standard ADS-B message set currently defined by RTCA DO- 
260B [3], The ability to perform flight tests with non-standard 
ADS-B messages enables updated ADS-B report structures to 
be instituted, alleviating the issue of attempting to test ADS-B 
avionics based on a nonexistent standard. 

Several applications have been developed by NASA and 
others that make use of ADS-B In. They have been investigated 
extensively using HITL and fast-time simulations. One 
example is Pair-Dependent Speed (PDS) guidance, which uses 
a trajectory-based spacing algorithm called Airborne Spacing 
for Terminal Arrival Routes (ASTAR) in the Flight Deck- 
based Interval Management (FIM) ConOps. Another is the 
Traffic Aware Planner (TAP) application which generates and 
displays an optimized flight path to flight crews within the 
Traffic Aware Strategic Aircrew Requests (TASAR) ConOps. 
Use cases for these two ConOps are provided in Section IV. 

Flight crew interfaces for TASAR and FIM have been 
developed and tested at NASA. The display presents visual 
outputs of applications to the flight crew and will exist on the 
on-board NATIVE hardware. The FIM ConOps requires a 
display be mounted to the glare shield in the pilot’s line of 
vision. A research prototype version of this additional display 
can be provided as part of the NATIVE installation. 

The NATIVE system may contain special elements 
depending on configuration and specific needs of the ConOps 
being tested. A CPDLC model could be utilized for some 
configurations of NATIVE in conjunction with emulated ADS- 
B. A virtual traffic generator may simulate traffic scenarios to 
enable more experimental control without exposing aircraft to 
unnecessary risk. In many instances, test aircraft may have 
access to an Internet traffic feed as well as ADS-B In data. A 
data fusion algorithm known as a scenario filter will enable 
control over the source of traffic information when choices are 
available. Some NATIVE configurations may also utilize 


software that gathers additional traffic information and/or 
weather information. Traffic information may be obtained 
either from FAA data feeds or from an Aircraft Situation 
Display to Industry (ASDI) data stream. Weather data may be 
gathered from National Oceanic and Atmospheric 
Administration (NOAA) Rapid Refresh or elsewhere. 

IV. Use Cases and System Configurations 

Two advanced NASA ConOps that require ADS-B In — 
FIM and TASAR — offer use cases to investigate the 
feasibility of the NATIVE concept. 

FIM is a concept that allows pilots to efficiently space 
aircraft along Standard Terminal Arrival Routes (STAR) to 
optimize runway throughput [4], Aircraft are given a target 
aircraft behind which to fly with a designated separation 
measured in time or distance. The desired separation interval is 
sent to the ASTAR algorithm from ATC, and the pilot makes 
throttle adjustments throughout the STAR until the final 
approach fix in order to match an interval requirement provided 
by a cockpit display of speed guidance [4], The benefits of 
utilizing FIM in integrated airborne and ground-based arrival 
management ConOps include relieving traffic congestion at 
airports, increasing runway throughput, reducing flight delays, 
and mitigating environmental effects such as noise and air 
pollution around airports. 

TASAR is a concept that enables the flight crew to perform 
in-flight replanning based on airline optimization preferences 
and generate flight plan changes that are approvable by air 
traffic controllers. TASAR's Traffic Aware Planner (TAP) is an 
EFB-based application that uses traffic, weather, winds-aloft, 
and restricted airspace information to advise the pilot of 
possible trajectory changes that would be beneficial to the 
flight, such as to optimize fuel efficiency or flight time [5], 
Potential benefits to users of TASAR are reduced fuel cost per 
flight, fewer in-flight miles, improved schedule compliance, 
less environmental impact, and increased passenger comfort. 

For both FIM and TASAR, three NATIVE architectural 
configurations were developed and analyzed for bandwidth, 
latency, computational load, and practicality. Figures 2 and 3 
summarize the principal data flow of the NATIVE system in 
each of the following FIM and TASAR configurations, 
respectively. NATIVE components are outlined in gray. 

A. FIM Configurations 

In FIM Configuration 1, the majority of the computing 
occurs on the flight deck. The NASA-developed PDS guidance 
application, the flight crew interface, and the ADS-B In and 
Out models are located on an airborne NATIVE computer. The 
necessary speed to maintain an interval will be displayed on the 
airborne NATIVE computer or separate display. A complete 
traffic picture is sent from the ground system to each aircraft, 
where it is then filtered by the ADS-B In reception model. 
Since all traffic information relevant to the test is uplinked to 
each participating aircraft, this configuration was expected to 
require high Internet throughput relative to other 
configurations. 

In FIM Configuration 2, the ASTAR and PDS algorithms 
are located on the airborne NATIVE computer, and traffic data 
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management occurs on the ground, as with FIM-1. In FIM-2, 
the ADS-B In model resides on the ground, filtering the traffic 
data to determine which ADS-B transmissions would be 
received by each participating aircraft. A specific set of traffic 
information is then uplinked to each participating aircraft. This 
reduces required bandwidth for the in-flight uplink portion of 
the Internet system, but bandwidth requirements and 
computational loads for the ground system are increased. The 
increased computations could introduce latencies since traffic 
information would be sent to all participating aircraft after all 
traffic computations are complete for the surveillance update 
interval. 



Figure 2: FIM Block Diagrams. 

FIM Configuration 3 manages the traffic picture on the 
ground. The ASTAR algorithm, ADS-B In model, and traffic 
integration software are also ground-based, requiring only a 
speed guidance message to be sent to each aircraft as an 
emulated CPDLC message. In this design, in-flight Internet 
throughput requirements are decreased considerably, yet 
latencies may exist because speed guidance is sent to each 
participating aircraft. Table 1 summarizes the three FIM use 
case configurations. 


Table 1 . FIM NATIVE Configuration Comparisons 



Traffic 
Sent to 
Aircraft 

Algorithm 

Location 

ADS-B In 
Model 
Location 

ATG“ 

Data 

GTA b 

Data 

1 

All 

Air 

Air 

Emulated 

ADS-B 

Emulated 
ADS-B or 
CPDLC 

2 

Partial 

Air 

Ground 

Emulated 

ADS-B 

Emulated 

ADS-B 

3 

None 

Ground 

Air 

Emulated 

ADS-B 

Emulated 

CPDLC 


a. Air-to-Ground 

b. Ground-to-Air 


B. TASAR Configurations 

NASA plans to conduct an in-flight assessment of the 
TASAR concept to accelerate readiness and make TASAR 
operations available to the aviation community for near-term 
operational use. The objective of the flight trial is to identify 
operational factors unique to the in-flight environment that may 
affect TASAR functionality, data requirements, interface 
requirements, and procedures. These early findings will help 
refine the TAP application and the TASAR concept. 

TASAR Configuration 1 represents a possible NATIVE use 
case for the planned TASAR flight trial. Flight trial goals could 
be expanded with NATIVE to increase the value of the trial. 
Some experiment goals may be achievable without the need for 
ADS-B on the test aircraft, so some cost reduction may also be 
possible, depending on the final choice of experiment 
objectives. For this configuration, only uplink capability is 
utilized. Traffic data provided by ASDI are uplinked to 
participating aircraft to either augment or replace information 
provided by on-board ADS-B. Convective weather and winds- 
aloft data from NOAA Rapid Refresh or elsewhere may also be 
uplinked. A NATIVE ground system is needed to collect and 
process these data feeds and format the data for uplink. Data 
processing may include polygonization of convective weather 
regions. On the test aircraft, a separate NATIVE laptop may be 
required to augment the data processing load of the EFB. This 
computer would receive ADS-B In inputs and compare them 
with ASDI data received via uplink. Duplicate targets would be 
removed by the scenario filter that would construct a traffic 
surveillance data set for use by TAP. Duplicate targets may 
also be used by this function to estimate latencies for data 
received through the uplink. If direct ADS-B In latencies are 
assumed to be insignificant, the availability of duplicate target 
information enables comparisons of the two sources of data, 
and the time of applicability for the uplinked targets may be 
adjusted for use in extrapolations of current target states. 
Depending on test objectives, the airborne NATIVE 
component may also host an ADS-B In emulation, which 
would filter uplinked ASDI traffic data and remove targets that 
would not have been received by an actual ADS-B system. 
High Internet bandwidth may be required for this 
configuration, and depending on the number of participating 
aircraft, latencies may also be high. 
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Figure 3: TASAR Block Diagrams. 

TASAR Configuration 2 emulates ADS-B surveillance so 
participating aircraft need not equip with ADS-B hardware. 
This configuration may be used for tests involving traffic 
aircraft that would be accounted for in the test aircraft’s in- 
flight replanning. Computational workload is distributed 
between the airborne component and the ground system. As in 
TASAR- 1, the airborne component hosts the TAP algorithm, 
interface, and the ADS-B models. Additional traffic and 
weather are localized on the ground system and uplinked to the 
aircraft. Emulated ADS-B data is sent between aircraft, but in 
this configuration, NATIVE can utilize ADS-B as well. 

TASAR Configuration 3 represents a hypothesized ATM 
cloud -computing scenario where the specialized TAP flight 
replanning and optimization functions are supported by a 
ground-based computer rather than a computer on the flight 
deck. In such a scenario, only a pilot interface exists on the 
EFB. The pilot would query a stand-alone TAP algorithm 
engine hosted by the NATIVE ground system. Crew 
optimization preferences are entered through the interface and 
downlinked to the TAP engine. The active flight plan, flight 
plan modifications, and all relevant aircraft-specific 
information are also downlinked. The TAP algorithm engine 
utilizes traffic and weather data feeds on the ground, and flight 
plan alternatives are uplinked via emulated CPDLC. Flight plan 
modification advisories are anticipated to be offered no more 


than once per minute. This configuration minimizes the amount 
of Internet throughput required, but latencies are still expected. 
Table 2 summarizes the three TASAR use case configurations. 

Table 2. TASAR NATIVE Configuration Comparisons 



Traffic 
Sent to 
Aircraft 

Algorithm 

Location 

ADS-B 
IN Model 
Location 

ADS-B 

System 

ATG" 

Data 

GTA b 

Data 

1 

All 

Air 

Air 

Optional 

N/A 

Emulated 
ADS-B + 
Weather 

2 

Partial 

Air 

Air 

No 

Emula 

ted 

ADS- 

B 

Emulated 
ADS-B + 
Weather 

3 

None 

Ground 

None 

No 

Emula 

ted 

ADS- 

B 

Emulated 

CPDLC 

+ 

Weather 


a. Air-to-Ground 

b. Ground-to-Air 


V. Technical Feasibility 

Internet bandwidth and latency requirements were 
considered for the architectural configurations of the 
aforementioned NATIVE use cases. The capabilities of three 
existing in-flight Internet systems were then estimated based on 
measurements obtained during commercial flights and 
consultation with the ISPs. The estimated capabilities were 
then compared with requirements to determine feasibility. An 
Internet latency impact assessment test was performed, and 
other factors and risks were also investigated. 

A. Bandwidth Requirements. 

Internet bandwidth required to support NATIVE-based FIM 
and TASAR ConOps during flight trials is derived from 
assumed upper bounds. A breakdown is given in Table 3 and 
ceilings for FIM and TASAR configurations are listed in Table 
4. When considering the bandwidth required to transmit 
ownship data or traffic information, it has been assumed that 
messages are sent in compliance with DO-260B. The ADS-B 
reception range of each aircraft has been estimated as a circle 
with a 90nmi radius with the ownship at the center. Overall 
NAS traffic density has been assumed from the LA Basin 2020 
scenario, where there are 2694 aircraft within 400nmi of the 
center [6]. The density has been applied over the approximate 
area of the contiguous United States [7], 

In FIM-3, speed guidance information sent to the aircraft 
was conservatively assumed to be a 64-bit floating point 
number, sent twice per second. In the case that ASDI traffic 
data is being used, the analysis assumed that each aircraft’s 
track information is contained in a 36-byte message and 
updated once per minute [8], Weather data was assumed to 
come from the NEXRAD mosaic at its uncompressed size of 
approximately 7MB over an update time of 5 minutes. In 
practice, the NEXRAD mosaic can be compressed to around 
300 kB [9] [10], For TASAR-3, ownship data is assumed to be 
293 bits broadcast at 2Hz [11], When transmitting intent data, 
the aircraft flight plan was conservatively assumed to consist of 
100 waypoints [11], Lastly, a 60-byte packet header over an 
IPv4 network has been assumed. This header is the largest in 
the IPv4 standard, which is the most common protocol for data 
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transmission over the Internet. Packet sizes are assumed to be 
68 bytes, which is the lower bound of this protocol and hence 
requires the transmission of more packets and therefore more 
headers, using more bandwidth. 


Table 3. Bandwidth Requirement Breakdown 


Data 

Bandwidth (kbps) 

Ownship ADS-B 

0.68 

All US NAS ADS-B 

7300 

ADS-B within 90nmi range 

720 

Speed guidance 

0.13 

National NEXRAD Mosaic 

190 

Ownship TASAR-required 

5.2 

Intent (100 waypoints) 

3.9 

All US NAS ASDI track 

52 


Table 4. Summary of Bandwidth Requirements for FIM and TASAR 
Configurations 



Downlink (kbps) 

Uplink (kbps) Upper Limit 

FIM 1 

1.7 

7300 

FIM 2 

1.7 

720 

FIM 3 

1.7 

0.61 

TASAR 1 

0 

460 

TASAR 2 

1.7 

1000 

TASAR 3 

10 

7.8 


B. Data Link Specifications 

Major providers of commercial in-flight Internet service 
utilize cellular or Ku-band satellite technology. Two in-flight 
ISPs — Gogo and Row44 — were examined to determine 
NATIVE'S feasibility for both Internet data exchange 
technologies. 

Gogo provides a ground-based cellular network within the 
continental United States and advertises a peak uplink 
bandwidth of 3.1 Mbps over their ATG-3 system. Gogo is 
currently installing ATG-4 with an advertised throughput of 
9.8Mbps [12] [13]. A test of the ATG-3 system measured 
latency and throughput characteristics on a Boeing 757 during 
the cruise phase of a single routine five -hour commercial cross- 
country passenger flight to obtain a limited sample of system 
performance. Connectivity to the aircraft's Internet system was 
shared among paid passengers throughout the entirety of the 
trip, so the test results may not be indicative of the expected 
performance capabilities for a NATIVE implementation. Using 
speedtest.net at five-minute intervals to obtain averages based 
on cellular tower location and potential temporal spikes in 
shared bandwidth usage, median uplink throughput of 100kbps, 
median downlink throughput of 82kbps, and a median latency 
of 560ms, were found. 

Row 44 provides Ku-band satellite Internet connectivity 
and claims a peak throughput of 11Mbps per aircraft [14] [15]. 
A test of Row 44 ’s Internet system measured latency and 
throughput characteristics on a Boeing 737 during the cruise 
phase of a single routine five-hour commercial cross-country 
passenger flight to obtain a limited sample of system 
performance. Connectivity was shared among paid passengers 


throughout the trip, so again, the test results may not be 
indicative of the expected performance capabilities for a 
NATIVE implementation. Using speedtest.net at five-minute 
intervals to obtain averages based on satellite coverage and 
temporal spikes in shared bandwidth usage, median uplink 
throughput of 340kbps, median downlink throughput of 
72kbps, and a median latency near 1200ms were found. Data 
for Gogo and Row44 are presented in Figure 4. 
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Figure 4: In-flight Internet Flight Test Results. 

C. Internet Latency Impact Assessment 

Several experiments were performed at Langley Research 
Center that investigated the impact of Internet latencies on FIM 
in a high-fidelity simulation environment with a three-aircraft 
stream comprised of a Boeing 757 in the lead, a Boeing 777 
first in trail and equipped with NATIVE, and Boeing 737 
second in trail and equipped with ADS-B. In these 
experiments, the three aircraft begin at 15, 21, and 26 nautical 
miles from a runway threshold at Dallas/Fort Worth 
International Airport, respectively. The NATIVE-equipped 
B777 is designated a 93s time interval behind the lead aircraft, 
and the B737 is given a 122s interval behind the Will . The 
experiments showed that the NATIVE-borne FIM algorithm 
withstood 25s +50% mean Internet latency and is unaffected by 
up to 2% dropped packets. Results of this study are presented 
in detail in [16], 

D. Other Technical Feasibilty Concerns 

Although the transmission of flight-critical data is not 
envisioned for flight tests, security should be addressed in the 
context of utilizing the Internet as a data link. It should be 
noted that ADS-B is currently an unsecured data link [17], The 
Internet, on the other hand, offers many methods of encrypting 
sensitive information. 

Reliability is also an issue that must be addressed. For 
example, coverage gaps in mountainous regions and legal 
constraints below 10,000 feet inhibit Gogo’s cellular signal at 
low altitudes; however, Gogo can temporarily install cellular 
towers near airports that would allow unfettered access for 
testing purposes. In the case where this will be necessary, 
software updates will be required for participating aircraft [13]. 
Also, because Row44 employs Ku-band satellite technology, 
rain fade is a practical concern. At roughly one inch of rain per 
hour, Ku-band satellite transmission is attenuated on the order 
of 5dB [18], 
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Message transmission integrity is another concern. The 
figures shown in Table 3 above are based on an assumption 
that TCP/IP will be the preferred data transfer protocol for the 
test arena. If the data link is reliable, TCP/IP ensures packet 
integrity. On the other hand. User Datagram Protocol (UDP) is 
a lighter and faster transmission protocol than TCP/IP; 
however, packet loss is a practical concern. 

E. Analysis Results and Conclusions 

An analysis of the technical feasibility of NATIVE has 
presented no major roadblocks with respect to throughput, 
latency, security, reliability, or integrity. 

Throughput characteristics of current cellular and satellite 
in-flight Internet systems can support NATIVE for FIM and 
TASAR. As shown in Table 4, the most substantial required 
throughput is roughly 7.3 Mbps for FIM-1; however, this value 
is based on the assumption that over one-thousand aircraft 
would take part in a test. Realistically, no more than 100 
aircraft would be involved in a test, so throughput requirements 
will likely not exceed 100kbps. The measurements of cellular 
and satellite Internet described in Section A above were taken 
during a typical revenue flight with at least 150 paid 
passengers, any number of whom may have been sharing the 
aircraft Internet system as well. Therefore, results from the 
throughput and latency tests likely reflect a low estimate of per- 
aircraft bandwidth capability. However, the uplink throughput 
for both experiments was measured to be at least 100kbps. 
Therefore, it can be concluded that throughput constraints will 
not hamper NATIVE'S feasibility. In the absolute worst case, 
where over one -thousand aircraft would take part in a FIM-1 
test, in-flight Internet service providers still advertise the 
capability to support even the throughput requirement specified 
in Table 4, with the exception of Gogo ATG-3, which cannot 
support the worst-case FIM-1 and FIM-2 configurations; 
however, at 9.8Mbps, Gogo ATG-4, as advertised, will support 
the worst case FIM-1 and FIM-2 cases. 

Measured latencies will not affect timely execution of 
ConOps. While simulator experiments perform inadequately 
after 25s, measured latencies of Gogo and Row44 were on the 
order of one second. Fatency will thus not present a limiting 
factor. 

Security should also pose no concern. While ADS-B is 
inherently an unsecure data link, an Internet data exchange 
offers many methods of encrypting sensitive information. For 
this reason, NATIVE will be sufficiently secured for a flight 
test arena. 

Signal reliability must be carefully considered. In the event 
that full-scale flight tests will commence in extreme rain 
conditions, Ku-band satellite service should be avoided; 
however, precipitation levels that will significantly affect Ku- 
band transmission reliability would also likely jeopardize flight 
test objectives. Therefore, rain fade is a minor concern. 
Coverage gaps below 10,000ft or in mountainous regions will 
hamper the reliability of Gogo’s cellular signal, but this can be 
solved with additional localized towers, albeit at increased cost. 
Reliability will not negatively affect feasibility. 

Assuming TCP/IP is the chosen data transfer protocol, 
integrity will be sufficient for NATIVE flight tests. Because of 


TCP/IP's error-correction schema, integrity is guaranteed. 
However, should the test environment utilize UDP, integrity 
must be further examined. 

VI. Preliminary Cost-Benefit Analysis 

A preliminary analysis was performed to examine the 
potential for cost savings through the NATIVE approach. Costs 
of a sample flight test using NATIVE were compared to those 
of a test that utilizes ADS-B in a traffic computer installation. 
A FIM test scenario with 15 participating aircraft was used for 
the analysis. FIM-1 was chosen because its data link bandwidth 
requirement was the greatest of the six use case configurations 
in Table 4. 

In a permanent configuration to be used in revenue service, 
FIM requires a traffic computer as specified in ARINC 
Characteristic 735B-1. The FIM ASTAR and PDS guidance 
algorithms reside inside the traffic computer, and crew 
interfaces are provided by a Class 3 EFB and the primary field- 
of-view Configurable Glass Display (CGD). All equipment and 
software are certified for revenue operation. Because NATIVE 
is intended to support flight validation of the concept rather 
than preparing for revenue service, the analysis compared two 
potential configurations suitable only for concept validation. 

For the NATIVE configuration, ADS-B equipage is 
emulated with on-board simulations of ADS-B and an in-flight 
Internet capability. FIM guidance algorithms and the ADS-B 
In/Out simulations reside on an EFB. All crew interfaces reside 
on the EFB and on an emulation of a CGD using a small 
computer attached to the glare shield. For the ADS-B equipage 
configuration, a traffic computer is installed, and the guidance 
algorithms reside on an EFB and the CGD is emulated as for 
the NATIVE configuration. Traffic information available to the 
EFB-based algorithms is limited to Display Traffic Information 
File (DTIF) data feeds from the traffic computer. 

Because the two configurations contain several common 
elements, several costs are identical and therefore not relevant 
to the comparison. These include supplemental type certificates 
(STC) and installation costs for Class 2 EFB hardware, costs of 
experimental certification, and costs to remove test equipment 
and perform regression testing to demonstrate original type 
certification. For the NATIVE configuration, participating 
aircraft were assumed to be pre -equipped with in-flight Internet 
services, and the costs to connect the in-flight Internet to the 
EFB were assumed to be negligible. Ground-based hardware 
costs and in-flight Internet subscription fees were included. 
Internet subscription fees were estimated from costs associated 
with a planned NASA TASAR flight test scheduled for 2013. 
The subscription requires a one-year contract that includes a 
limited amount of data usage, and additional fees are charged 
for supplementary data usage. [19] To determine uplink 
bandwidth requirements, traffic data were limited to 127 total 
traffic aircraft to allow direct comparison with the ADS-B 
equipage case. Internet data usage requirements assumed a 
flight test duration of ten hours using the FIM-1 configuration 
with the aforementioned traffic limitation of 127 targets. Using 
the calculated bandwidth requirement and assumed flight test 
time, the total amount of data transmitted and received does not 
exceed the data ceiling of the Internet subscription. Costs of 
NATIVE software development are not included. For the ADS- 



B configuration, hardware costs, system integration costs, and 
STC costs were included and based on the ADS-B AIWP, and 
assumed an in-production retrofit installation of a digital 
narrow-body ADS-B In/Out system without a multi-mode 
receiver. [20] 

The analysis shows that about $3.3M can be saved through 
the use of NATIVE for the example scenario. In light of 
necessary up-front infrastructure investments, a single 
NATIVE flight test may offer moderate savings, but significant 
savings may be obtained from repeated use because NATIVE- 
equipped test aircraft may be reused in future tests. Benefit 
mechanisms described in Section II should translate into 
significant savings for most tests. 

The capability to validate advanced technologies on test 
platforms rather than on certified avionics systems may be the 
single greatest cost-reduction mechanism resulting from the use 
of NATIVE. The capability to validate candidate message 
standards may also provide a large benefit, and specifically for 
ADS-B, the use of NATIVE enables the exploration of future 
ConOps that may rely on the surveillance of more than 127 
targets. Although these benefits may not translate directly into 
cost savings, they will enable early adoption of ADS-B in a 
timely manner by supporting maturation of ConOps that 
benefit users. Ultimately, NATIVE offers a bridge toward 
accelerated ADS-B standardization and validation of NextGen 
ConOps. Direct cost savings are achieved during standards 
maturation. More than one flight test will be necessary, and 
because airlines are hesitant to invest in them, a need exists to 
enable multiple reduced-cost flight tests. 

Table 5 . Comparison of Cost Requirements between NATIVE and 
ADS-B in a similar Flight Test 



ADS-B Test 

NATIVE Test 


$235. 39K per aircraft [20] 


Data Link 
Hardware 

Assumptions : Estimates 
from AIWP document for 
ADS-B In/Out; Equipment 
is digital narrow body 
without multi-mode 
receiver; Assumes retrofit 
to in-production aircraft. 

$0 

Assumptions'. Aircraft 
utilizes pre-installed in- 
flight Internet system; EFB 
connection costs are 
negligible. 

Ground-based 
Hardware and 
Software 

$0 

Not required for ADS-B 
test 

$20K 

Assumptions : Rough Cost 
Estimate. 

Internet 

Subscription 

Fee 

$0 

Not required for ADS-B 
concept 

$17.5K per aircraft [19] 

Assumptions'. Internet 
subscription cost based on 
planned NASA TASAR 
flight test. 


VII. Growth Potential 

By reducing costs and time required for flight trials that 
involve extensive air/ground data exchange, research and 
concept exploration may also be conducted for network 
concepts such as cloud computing applied to ATM. For these 
network-based concepts, the point of computation is not the 
same as the point of use, so new or updated available functions 
need not reside on the flight deck. This may significantly affect 
certification, equipage down time, and recurring costs of 


system functionality. An air/ground network infrastructure may 
facilitate fee-for-service capabilities and performance-based 
services that may prove to be critical enablers of benefits- 
driven airspace system modernization. 

It may be possible for some services to be available in the 
near term if they do not adversely impact flight safety. 
TASAR-3 is an example of such a service. In this example, 
operators may choose to subscribe to an in-flight replanning 
optimization service. The service provider would receive 
specific information for the operator's aircraft as well as airline 
or flight crew preferences for optimization. The service 
provider would host the optimization function and use Internet 
uplink capability to provide flight plan modification 
alternatives to the crew. The crew would use the service 
through an EFB-based thin-client interface. 

NAS delays amount to $8B/year in lost revenue, so an 
opportunity exists for cloud-computing entrepreneurial visions 
to utilize the NATIVE concept to increase NAS and airline 
efficiencies [21], Fuel burn is hampering airline profit margins, 
so demand exists for methods to deliver increased efficiencies. 
In order to determine the cloud concepts' technical feasibility, a 
further study of the accuracy, integrity, and security of in-flight 
Internet must be undertaken. 

Larger long-term opportunities afforded by the operational 
use of Internet to transfer flight data among aircraft and ground 
stations should also be considered. While congestion issues 
with 1090MHz hamper the expansion of the ADS-B message 
set, passengers aboard commercial flights use the Internet to 
send and receive data with no effective restrictions on content. 
Row44 is capable of increasing per-aircraft throughput and 
dedicating bandwidth in order to separate potential future flight 
application data exchange from retail passenger service on the 
flight deck [22], Contingent upon availability, reliability, 
security, and integrity meeting application certification 
requirements, if an aircraft streamed data from the FMS and 
other aircraft systems to ground stations, applications not yet 
possible with currently envisioned data links may be possible 
and cost-effective through the use of the Internet. 

VIII. Conclusion 

It is feasible to employ NATIVE in flight trials to emulate 
data links such as ADS-B. Each of the in-flight ISPs can 
provide viable Internet access through which to validate 
NextGen ConOps and message content standards. Certification 
and installation of NATIVE components is cost-effective. 
Economic benefits provide a positive investment case for 
NATIVE, and preliminary findings suggest that NATIVE'S 
value increases with the number of flight tests to be performed. 

NATIVE may indeed accelerate the adoption of ADS-B In 
by enabling reduced-cost in-flight validation testing of air-to- 
air and air/ground data links, associated applications, and 
solidification of message content standards. NATIVE’S 
scalability and adaptability enable evaluation of ConOps that 
are not supported by current avionics standards. NATIVE can 
inform discussions about the values intrinsic to alternative 
message sets. Airlines, application developers, and research 
organizations can develop test platforms for use with NATIVE 
to validate new ConOps and generate data that can be used to 
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estimate their benefits with high accuracy, without incurring 
expensive avionics costs and without limitations of currently 
available equipment. 
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